1. Field of the Invention
This invention relates to a method, system and computer program product for connecting to a remote Virtual Environment without a need for user authentication and identification, and to organizing communication between a client and a server.
2. Description of the Related Art
In a conventional client/server model, there are essentially two ways for a client to interact with a server—where the user is an anonymous user, for example, where a web page that does not require user identification and authentication is requested, and where user authentication is required. A common way to authenticate a user is through the user providing a server with his user ID and a password or via some device like smartcard. More complicated mechanisms involve not just information supplied manually by the user, but also other information that can be derived from the session, such as the user's IP address. Even more complex mechanisms, include providing a random number generating token to a user, where the user, to authenticate himself, needs to provide the numeric value that is displayed on the token, and that numeric value is then matched against the value that the server generates. One problem with this approach is the administrative burden inherent in the centralized administration of user access to his VE.
FIG. 2A illustrates a typical conventional scheme for online authentication and encryption that uses a standard secure socket layer (SSL) protocol, which can be used when a client attempts to access secure data in some remote storage. The SSL protocol provides for authentication and secure transmission of data over the Internet.
The authentication/authorization process typically requires two stages, as shown in FIG. 2A. In step 200A, the client 20 and the server 220 connect. At this point, the encryption/decryption protocols are set up, and cryptographic keys are exchanged. The client and the server establish a connection using a handshake. During the handshake process, the client and the server “agree” regarding the protocol for data exchange and the parameters used for establishing a secure connection, see http://en.wikipedia.org/wiki/Transport_Layer_Security, incorporated herein by reference in its entirety. In step 201A, for both the client and the server to be certain of who is on the other side of the connection, the server requests user credentials from the client, and the client provides the user credentials to the server. The server checks the user credentials, and, if successful, a secure connection to the client is established from a target machine in the repository, see step 202. Having access to protected resources, in step 203, the sending and receiving begin transmission of the data using the secure protocol.
FIG. 2B illustrates a more detailed process of the standard process of authentication and encryption using SSL. As shown in FIG. 2B, the client sends a CLIENT_HELLO message to the server, identifying the latest version of the TLS protocol that the client supports. The client also sends a random lead generated number and a list of encryption and compression methods that are supported on the client, and which are compatible with TLS.
The server responds with a SERVER_HELLO message, which contains: the protocol version selected by the server, a random number sent by the client, an appropriate encryption algorithm and compression algorithm that are selected from the list sent by the client.
The server then sends a server certificate to the client. The server certificate includes the server's digital certificate, which depends on the encryption algorithm. The server also sends a server key exchange message, which contains an open key. The server also sends a certificate request message, and then an EOM, which defines the end of the handshake.
The client and the server then establish a client certificate/certificate chain, which includes the attribute certificate with the user credentials. Using the open key and randomly generated numbers, the client and the server both calculate a common secret key (207B). All the rest of the information about the key will be derived from the common secret key, where were generated by both the client and the server based on random numbers. The client then sends a message to the server, which tells the server that all the remaining information will be encrypted using the algorithms established during the handshake, and using the secret key (208B). The client then sends a FINISHED message (209B), which contains a hash value and the authentication code for the messages generated based on the previous handshake exchange.
The server then attempts to decrypt the finished message (210B) from the client and to confirm the hash and the code. If the process of decryption or the verification is impossible to perform, then the handshake is considered to have failed, and the connection will be broken.
The server also sends an encrypted FINISHED message, and the client also attempts to perform the decryption and verification, see http://en.wikipedia.org/wiki/Transport_Layer_Security, incorporated herein by reference in its entirety.